Agent Memory vs Context Substrate

Agent 基础设施中处理长期信息的两种根本不同范式。

核心区分

Camp 1: Memory Backends

共同循环：对话发生 → 系统提取事实或存储内容 → 事实进入数据库（向量、图或两者） → 下次对话检索相关事实注入。

代表工具：

• Mem0（53.1k stars）：四级操作（add/search/update/delete），三层存储（user/session/agent），混合检索。局限：记忆是扁平条目，无关系，提取质量完全依赖 prompt。
• MemPalace（46.2k stars）：本地优先逐字记忆，wing/room/drawer 组织，ChromaDB 检索。LongMemEval 96.6% 召回。局限：线性增长，无压缩合成。
• Supermemory（21.8k stars）：显式定位"记忆不是 RAG"，时间感知（过期事实自动遗忘），多模态连接器。自创 MemoryBench 框架。
• Honcho（2.4k stars）：将人类和 agent 视为"对等体"，异步推理服务推导心理洞察，PostgreSQL + pgvector。
• Cognee（15.4k stars）：向量搜索 + 图数据库关系推理。
• Memori（13.3k stars）：拦截 LLM API 调用捕获执行上下文，LoCoMo 81.95% 仅用 4.97% 上下文 token。

Camp 2: Context Substrates

共同循环：agent 读取结构化上下文 → 在上下文中工作 → agent（或后台进程）写回结构化上下文 → 下次会话上下文更丰富。

代表工具：

• OpenClaw（358k stars）：纯 markdown 文件（MEMORY.md / YYYY-MM-DD.md / DREAMS.md），无向量数据库，无提取管线。做梦机制：light sleep（筛选分组）→ REM（加权回忆提升）→ deep sleep（晋升 MEMORY.md），阈值门控（最低分 0.8 / 最少回忆 3 次 / 最少独立查询 3 次）。
• Zep（4.4k stars）：从"memory" rebranded 为"context engineering"，时序知识图谱（Graphiti），valid_at / invalid_at 时间戳，预格式化上下文块，sub-200ms 检索。
• Thoth（145 stars）：个人知识图谱，10 实体类型 + 67 类型化有向关系，FAISS + one-hop 图扩展。dream cycle： nightly 四阶段（0.93+ 相似度合并 → 描述丰富 → 关系推断 → 90 天以上关系置信度衰减），三层防污染机制。
• TrustGraph（2.0k stars）："Context Cores" — 可移植、版本化的上下文包（领域 schema + 知识图谱 + 向量嵌入 + 证据源 + 检索策略），将上下文视为一等制品（版本控制、测试、晋升、回滚）。
• MemSearch by Zilliz（1.2k stars）：markdown-first，Milvus 作为"影子索引"，文件是真相来源，向量搜索只是访问层。

关键洞察

Camp 1 解决的是"事实回忆"："我三周前说了什么关于 X？" benchmarks 证明 96%+ 准确率、sub-200ms 延迟、drop-in API 已足够。

Camp 2 解决的是"上下文复利"：agent 需要在包含活跃项目、协作者、近期决策和昨日事件的上下文中运行，且这个上下文明天要比今天更丰富。

作者预测：6 个月内"context engineering"将取代"memory"成为严肃 agent 基础设施的默认术语。

Model-Harness-Fit 与生产记忆系统 (2026-05-03)

来源：Agent Memory Engineering

对 Hermes、Codex CLI 和 Claude Code 三者记忆实现的逐层拆解表明：

• Model-Harness-Fit：模型在其 Harness 上 post-train，记忆行为不可跨 Harness 移植。64 条 Claude Code 记忆放入 Codex 文件夹，bytes 落地但行为不同
• 简单栈获胜：LLM + markdown + filesystem tools 击败所有向量数据库和知识图谱方案。Agent 需要原始文件工具、markdown 约定和 prompt discipline，而非 bespoke memory infrastructure
• 前缀缓存是硬约束：动态记忆必须放在 user message 或 tool call 中，不能注入系统提示。22K tokens 系统提示若每轮变动，成本差达 10 倍
• Signal gate 比数据结构更重要：Codex 的默认 no-op 设计是控制噪音的关键——让模型证明值得记住，奖励空输出
• 验证纪律是最被低估的模式：Claude Code 每次读取记忆 body 时注入动态 age reminder，使记忆成为 hint surface 而非 authority surface

详见 Production Memory Systems。

Claude Code 的两层记忆机制（2026-05-05）

来源：十字路口播客 — 对谈来新璐

新璐通过对 Claude Code 源码的分析，揭示了其两层记忆机制：

1. Stop-hook Fork Agent（实时层）

每轮对话完成后 fork 一个 agent，复用 KV cache，判断需要保存什么，更新到结构化的 markdown 文件：

• 文件前 3 行为 YAML，像 skill 一样写 description
• 先按文件名和 description 筛选，再加载全文
• 实现了记忆的分级索引——避免一次性加载所有记忆

2. Auto Dream（离线层）

每天一次的后台整理，触发条件：至少 >5 个 session：

• 后台 agent 对近期对话做重放和信息整理
• 纠正错误事实
• 合并相似记忆

与其他记忆范式的对比

Claude Code 的记忆设计是 Context Substrate + Memory Backend 的混合体：

• Stop-hook fork agent 写入 markdown 文件（Context Substrate 模式）
• Auto Dream 进行异步的后台整理和合并（Memory Backend 的"提取"逻辑，但写入对象仍是文件）
• 关键差异：Claude Code 不做向量检索，完全依赖文件名+description 的文本匹配

上下文压缩的精妙设计

• 多级压缩策略：踢掉垃圾 → 设置阈值触发交接
• 上下文接力：写文档记录进度 → 新 Agent 读取 → 继续工作
• 哪些信息保留、哪些恢复、哪些让 Agent 按需查看——大量工程 trade-off

Anthropic 梦境代理的生产规模实践（2026-06-08）

来源：AI 简报 2026-06-08 Morning

Anthropic 构建了可并行运行的梦境代理系统，在用户下线后自动复盘会话：

• 每个会话一个梦境代理，最多可同时运行 100 个
• 95% 的 token 被缓存，使得完整记忆重写几乎免费
• 功能包括：核查输出、合并重复记忆、清除过时数据

这与 Claude Code 的 Auto Dream 机制形成对照：

关键洞察是：梦境代理将记忆维护从"每日批处理"推进到"会话级实时处理"，且通过缓存将成本压到接近零。这验证了 Context Substrate 模式中"文件即真相来源"的可扩展性——即使处理规模扩大 100 倍，只要保持前缀稳定并利用缓存，成本不会线性增长。

案例研究：Hermes Agent 的四层记忆 (2026-04-30)

来源：Manthan Gupta 深度拆解 Hermes 记忆系统

Hermes 是两种模型的有趣混合体：它用 Context Substrate（MEMORY.md / USER.md 文件），但刻意极致精简，同时用 Memory Backend（SQLite session_search + Honcho）处理长尾信息。

四层架构

与 OpenClaw 的关键差异

Hermes 的设计哲学：记忆应该让 agent 变得更好用，而不是通过摧毁提示词稳定性来换取博闻强识。 真正的诀窍不是记住更多，而是在正确的层级、以正确的成本，记住正确的事情。

关键设计决策

1. 字符限制而非 Token 限制 — 记忆逻辑与模型无关
2. § 分隔符纯文本 — 无向量数据库、无自定义二进制存储
3. 记忆冲刷（Memory Flush） — 压缩前先让模型保存关键事实到 MEMORY.md，牺牲任务细节保留用户偏好
4. Honcho 的缓存兼容集成 — 首轮织入系统提示词，后续附加在用户提问后（不破坏缓存前缀）

Session as Append-Only Event Log：两种范式之外的第三种模式 (2026-05-02)

来源：Addy Osmani — Long-running Agents

Addy Osmani 在分析 Anthropic / Cursor / Google 三家长时间运行 Agent 实践后，发现了一种不同于 Memory Backend 和 Context Substrate 的第三种持久化范式：Session 作为追加式事件日志。

与前两种范式的对比

关键设计属性

• 追加式（append-only）：不修改已有条目，避免破坏历史记录的完整性
• 事件粒度：记录"做了 X 决策"而非"模型当时在想什么"，避免上下文膨胀
• checkpoint 嵌入：在关键节点显式保存 goal（而非摘要），防止 alignment drift
• 恢复机制：Agent 恢复时读取 log 重建上下文，只加载当前工作窗口，而非全部历史

与其他两种范式的关系

一手源与二手源的权衡（2026-06-07）

来源：AI 简报 2026-06-07

Matt Pocock 将上下文工程定义为"管理一手源与二手源之间权衡的实践"：

这与 Context Substrate 和 Memory Backend 的区分形成互补：

• Memory Backend 通常输出二手源（压缩后的摘要、提取的事实）
• Context Substrate 更接近一手源（原始文件、结构化上下文）
• Session Event Log 保留一手事件，但在恢复时可能被重放为二手上下文

关键设计问题不是"要不要压缩"，而是"在哪些决策点保留一手源、在哪些点接受有损压缩"，以及"如何量化信息损失"。

跨平台共享记忆：Vox 的 shared brain 实践（2026-05-14）

来源：Vox — The First Step in Building My AI Native Team

Vox 在多 agent 平台（openclaw + hermes）之间部署了一个共享记忆层（gbrain），解决"两个 agent 各自记住同一决策但互不知晓"的问题。

核心洞见：

• 共享大脑不是 Context Substrate 也不是 Memory Backend，而是一个独立的 curated team-level facts 层
• 每个 agent 保留私有笔记本（个人习惯、临时上下文、角色特定经验）
• 共享层只存放跨 agent 持久有效的信息：长期决策、稳定事实、重要关系

与两种范式的关系：

• Context Substrate 解决"agent 在自己的文件上下文中工作"的问题
• Memory Backend 解决"agent 回忆用户说过什么"的问题
• Shared Brain 解决"多个 agent 之间的知识共享"的问题——这是前两者未覆盖的第三维度

Vox 提出了实施前的四个关键问题（什么属于单个 agent、什么是团队事实、谁有权写入、什么永远不入共享层）和七步实施顺序。详见 Shared Brain First, Boundaries Second。

Session Event Log 不是替代品——它与 Context Substrate 互补：

• Context Substrate 提供"这个领域应该知道什么"（知识积累）
• Session Event Log 提供"刚才发生了什么"（运行连续性）

一个长时间运行的 Agent 需要两者：Context Substrate 让它不重复犯错，Session Event Log 让它中断后能无缝继续。

memory-layered context：治理记忆如治理微服务

Addy Osmani 提出将记忆按访问频率分层：

这套分层与 Hermes 的设计（见 #案例研究：Hermes Agent 的四层记忆 (2026-04-30)）形成对照——Hermes 用 SQLite 处理温数据、Honcho 处理冷数据，但缺少显式的 Session Event Log 层。